About GeoTools 2

Perhaps the most important understanding needed about the design of GeoServer is the incredibly close linkage with GeoTools2. Browsing the GeoServer code likely gives one less than half of the understanding needed to comprehend what exactly is going on. This is by design, the GeoServer Project does not want to reinvent the wheel with yet another feature model, so instead we have worked extensively with GeoTools to improve their feature model to handle the functionality GeoServer needs. GeoTools does all the 'heavy lifting', the reading and writing to datastores, the querying and filtering, the rendering and generation of GML. So many GeoServer improvements and bug fixes actually fall into the GeoTools code base. This has the nice effect of having even more eyes to find bugs, as other projects make use of GeoTools, and there are more developers there to put their minds on improvements. For any serious GeoServer development work we highly recommend getting acquainted with GeoTools, the best place to start is with the Developer's Guide. GeoServer follows most all the same conventions and philosophy as GeoTools, so that guide should serve as a good guide for GeoServer as well. As GeoTools is a huge code base we will also discuss the parts that GeoServer makes use of. GeoServer 1.3 works against GeoTools 2.1.

Relevant GeoTools2 Design

We think GeoTools is easily the best open source Java GIS toolkit. Of course we're a bit biased, since we've put a ton of work into it, but it has grown to become quite nice to work with. More hints on working with GeoTools and GeoServer can be found here. For now we just want to hit a bit on the design and history. GeoTools 1 was focused on applet development, and ended up as a decent toolkit, but soon the developers wanted a much more robust and scalable Java toolkit. The interfaces of GeoTools are based as much as possible on OpenGIS specifications. The core packages that GeoServer works with are Feature, which is the core model, Data, which does the transformation to and from GeoTools and various other formats, Filter, which contains a model for Filtering data based on spatial and non-spatial attributes. And with the integration of the GeoTools WMS, GeoServer now makes use of the Renderer and Style packages as well. GeoServer also contributed a new package to GeoTools called 'Validation', which performs user defined validation of transactions on features. Note that the GeoServer 1.2 series works against GeoTools 2.0.x branch, and 1.3 works against the trunk (2.1.x will be the branch when trunk moves on).

Feature

A Feature is the atomic unit of GIS processing, it is generally a geometry, with zero or more non-spatial attributes. It most often corresponds to a row in a table or a line in a file. In GeoTools it is made up of one or more Attributes, which can be any Java objects. GeoTools does not provide its own Geometry implementation, it makes use of the excellent JTS Topology Suite. Each Feature also has a FeatureType, which contains the meta information about the Feature. In database terms a FeatureType is the table, it contains information of what types of Features are contained in a set of data. Each FeatureType is made up of one or more AttributeTypes, which roughly correspond to columns in a database. An AttributeType has a name and a type (java class), and can perform parsing (such as if it is a double type and is given a string), and validation. One thing to note about GeoTools is that the various kinds of AttributeTypes are buried as inner classes in DefaultAttributeType. We are hoping to change this sometime soon. The last piece of the feature puzzle is the FeatureCollection. This extends java.util.collection, so most java developers should instantly recognize its methods. We are looking into making collections more strongly typed, so that it could say limit Features added to a single FeatureType. But FeatureCollections will currently take any Feature, the one additional function they have is returning the bounds of the Features contained.

Filter

Filter is directly based on the OGC filter specification. It additionally contains classes to read to and from xml representations of Filters, using both SAX and DOM, so a programmer can use whatever she prefers. The Filter packages also contains SQLEncoders, which will translate filters into appropriate SQL WHERE clauses. The SQLUnpacker can be used to process what filters to pass to the encoder, and what to filters should be used for post-processing after the select statements has been made.

Data

The Data package is the package of most interest, and the one which GeoServer has put the most work into, as GeoServer relies quite heavily on access to and from data. The latest incarnation of the package is focused on making it as easy as possible for new users to write implementations of DataStore, the basic data access class. Jody Garnett has written up a complete tutorial on writing a new DataStore, and we recommend that as a solid introduction to the Data package, and a great example of how someone can add their data format to GeoTools. GeoServer is very interested in supporting as many formats as possible, so any DataStore implementation in GeoTools is a great contribution to the GeoServer project. Note that adding a DataStore to GeoServer involves absolutely no code in GeoServer itself. GeoServer has no knowledge of specific DataStores, only the DataStore interface, and the plug-in mechanism that GeoTools provides. Each DataStore contains its own jar, which contains meta information about the Factory it provides, and the Factory tells what parameters it can process and return a DataStore with. There are several advanced DataStore topics, such as filter unpacking and fid generation, but we shall leave them off here, if interested please email the list and we can reply on there and then add the results to this guide.

Style

Style is directly based on the OpenGIS Styled Layer Description (SLD) specification. The package provides a java implementation of Styles, and xml encoders and decoders to read to and from the SLD language.

Rendering

For Rendering GeoServer currently makes use of the LiteRenderer (org.geotools.rendering.lite). There is also a more advanced J2d renderer, but it focuses on complex caching and better zoom speeds, which GeoServer does not care about, since a WMS is essentially stateless. The LiteRenderer does not take as much time to perform the first rendering, which is the only rendering which GeoServer cares about. Both renderers make use of JAI (Java Advanced Imaging), and we encourage users to install the version specific to their operating system, as it will perform much better.

Validation

GeoTools also contains a number of classes for Validation processing. This is an extension done by the team at Refractions Research, to allow organizations to define a number of validation rules so as to not corrupt the backend database that the WFS is connected to. The validation rules are defined using various plug-ins that are configured with an xml based language, which also contains a nice UI through the GeoServer web administration interface. After defining the various validation rules, such as 'don't allow empty geometries', or 'all roads must be of length 200 or over', or 'houses are not allowed to be located in lakes', then all transactions are automatically checked, and the whole transaction is not allowed if any break the rules. For more information about validation processing we recommend getting in touch with Refractions.